In a prior database system that is accessible using a database access statement of SQL (Structured Query Language) or the like, an application program has had access thereto via middleware such as CLI or the like. One example of such middleware is ODEC (Open Database Connectivity) of the Microsoft Corp.
FIGS. 1 and 2 illustrate a configuration for implementing CLI in a database that may use an SQL database access statement. More particularly, FIG. 1 illustrates a system of the client/server type, which implements the aforesaid CLI. In case of accessing an SQL server 120 from an application 112 on an SQL client 110, an SQL instruction embedded within application 112 is sent to the SQL server 120 via an ODBC/CLI driver 114. A database engine 122 on SQL server 120 executes the received SQL instruction to process data 130 and to return the processed result to application 112 via the ODBC/CLI driver 114.
This is illustrated in FIG. 2 in more detail. In FIG. 2, a search statement or an SQL update statement, pursuant to the protocol of ODEC/CLI and embedded in a unique language of the package software (application software) 112, is rendered to be a universal SQL statement, which is then passed to the ODEC/CLI driver 114. In this ODEC/CLI driver 114, such a statement is transformed to an SQL dialect that is unique to a database to be accessed, which is then sent to SQL server 120. Using this SQL dialect, database engine 122 on database server 120 processes data 130.
Heretofore, an attempt has been made to extend an SQL database of the type that supports data comprising single byte characters (single byte character set: SBCS) alone, thereby enabling to support data comprising double byte characters (double byte character set: DBCS) such as Kanji or the like. For example, in the SQL defined by Japanese Industrial Standards (JIS), whenever DBCS data representing Kanji or the like is to be accessed, syntax different from that of SBCS is introduced. This is illustrated in FIGS. 3a and 3b.
In a database shown in FIG. 3a, double byte data such as "D1D2" (where each of "Dl" and "D2" stand for a double byte character) or the like is stored as single byte data. In such a case, all data is accessed with the syntax of CHAR type. FIG. 3b shows that if the database shown in FIG. 3a is enhanced to support NATIONAL CHARACTER (NCHAR) or migrated to a new database which supports NATIONAL CHARACTER (NCHAR), it will be necessary to add "N" indicating NCHAR before literal of the data for accessing the corresponding data item. In another words, any syntax that is not provided with such "N" will result in an error.
However, in the conventional CLI, CHAR type has been defined as a sole data type. Namely, it has not been possible to specify NCHAR type and, thus, there has been no way to access any database having data of NCHAR type.